Unix: unmount all volumes when a new USB or Thunderbolt device is connected - #1984

Related to #1982 (the Windows part is #1983).

On Linux and macOS, VeraCrypt has no equivalent of "Clear encryption keys from memory if a new device is inserted". This PR adds one to Preferences > Security > Unmount All Volumes When: "A new USB or Thunderbolt device is connected".

• Detecting devices. The GUI listens to kernel uevents on Linux (netlink, kernel messages only) and to IOKit first-match notifications on macOS. Devices connected when the option is enabled, or when VeraCrypt starts, are ignored. A device is identified by vendor, product and serial number, or by its port if it has no serial number.

• On a new device. The password cache is wiped, then all volumes are unmounted even if files are open. A device connected while a wait dialog is open, or while volumes are being unmounted, is handled afterwards.

• Linux: keys erased immediately. A forced unmount detaches the filesystem lazily, and the device-mapper devices are only removed once they are closed. So the keys would stay in memory while any file on the volume is open. This option therefore:

  • first replaces the table of the device-mapper devices of all volumes with an error target (DestroyVolumeKeys, dmsetup wipe_table --noflush --nolockfs), which frees the dm-crypt keys at once;
  • then cleans up each volume with EmergencyDismountVolume in a new destroyKeys mode, which aborts the volume's FUSE connection (/sys/fs/fuse/connections/<n>/abort, mounting fusectl there if needed) once its loop and device-mapper devices are released. The FUSE service then closes the volume, which erases its keys, and exits. --emergency-unmount is unchanged.

  Open files then fail with I/O errors, and their unsaved data is lost. The warning shown when the option is enabled says so.

• macOS. A forced unmount (hdiutil detach -force) already releases the FUSE service. Discovery is the one the other automatic unmounts use, so a stalled FUSE-T mount blocks this too.

• Linux preferences. Only this auto-unmount option is shown; the others stay hidden because unmounting may require the administrator password. If VeraCrypt has not obtained administrator privileges in the session, it asks for the password before unmounting, and the warning says so.

• Lock. When the option is enabled, the user can also lock it. Until the session ends, the option cannot be disabled, the background task cannot be turned off, and VeraCrypt cannot be closed. The lock does not protect against someone who can run programs in the session, who can terminate VeraCrypt; the prompt says so.

Testing:

• Tests/test_linux_new_device_unmount.py runs as root against the installed GUI under Xvfb. It refuses to run while other VeraCrypt volumes are mounted. It mounts a volume with kernel cryptography and one without, with a file open on each, and checks that:
  • a device connected before the GUI started does not unmount anything when the kernel reports it again;
  • a new USB device unmounts both volumes;
  • both open files then fail with EIO;
  • the device-mapper devices are removed or hold an error table;
  • no auxiliary mount remains and no VeraCrypt process still holds /dev/fuse.
• The test is in build-linux.yml. It is skipped on the GitHub runners, whose Azure kernel has no dummy_hcd module.
• I ran it in an Ubuntu 24.04 VM (kernel 6.8) with the GUI package built by this workflow, using QEMU's real USB hotplug (--connect-command). All checks pass. A second run with /sys/fs/fuse/connections unmounted passes too: VeraCrypt mounts fusectl itself.
• The macOS code (NewDeviceMonitor.cpp and the changed GUI and Core files) only passed a clang++ -fsyntax-only check against Homebrew wxWidgets on a macOS runner. I do not have a Mac, so it is neither linked nor run-tested.

Known limits:

• A device is recognized by what it reports (vendor, product, serial number) or by its port. A device that imitates one connected at start is not detected; the Windows option has the same limit.
• FireWire and PCI hotplug are not watched.
• If hotplug events are lost (ENOBUFS), connected devices are compared with those known at start, so a device connected and removed again meanwhile is missed. Treating the loss as a trigger would let a udevadm trigger burst unmount every volume.
• A FUSE worker blocked on backing-file I/O keeps its keys until that I/O returns.
• The test runs the GUI as root, so the path through the elevated service of a non-root GUI is not covered by it.
• A lock does not survive VeraCrypt being terminated.

Since I cannot test on Windows or macOS, please feel free to merge this, close it, or take it as a basis for your own implementation, as you see fit. I will adjust the Linux/Unix part according to your suggestions.